B2BUA and Stateful Proxy Operating Modes
The device can operate in one or both of the following SBC modes:
|
■
|
Back-to-Back User Agent (B2BUA): Maintains independent sessions toward the endpoints, processing an incoming request as a user agent server (UAS) on the inbound leg, and processing the outgoing request as a user agent client (UAC) on the outbound leg. SIP messages are modified regarding headers between the legs and all the device's interworking features may be applied. |
|
■
|
Stateful Proxy Server: SIP messages traverse the device transparently (with minimal interference) between the inbound and outbound legs, for connecting SIP endpoints. |
By default, the device's B2BUA mode changes SIP dialog identifiers and topology data in SIP messages traversing through it:
|
■
|
Call identifiers: Replaces the From-header tag and Call-ID header so that they are different for each leg (inbound and outbound). |
|
●
|
Removes all Via headers in incoming requests and sends the outgoing message with its own Via header. |
|
●
|
Doesn't forward any Record-Route headers from the inbound to outbound leg, and vice versa. |
|
●
|
Replaces the address of the Contact header in the incoming message with its own address in the outgoing message. |
|
■
|
Replaces the User-Agent/ Server header value in the outgoing message, and replaces the original value with itself in the incoming message. |
In contrast, when the device operates in Stateful Proxy mode, the device by default forwards SIP messages transparently (unchanged) between SIP endpoints (from inbound to outbound legs). The device retains the SIP dialog identifiers and topology headers received in the incoming message and sends them as is in the outgoing message. The device handles the above mentioned headers transparently (i.e., they remain unchanged) or according to configuration (enabling partial transparency), and only adds itself as the top-most Via header and optionally, to the Record-Route list. To configure the handling of these headers for partial transparency, use the following IP Profile parameters (see Configuring IP Profiles):
|
■
|
'Remote Representation Mode': Contact and Record-Route headers |
|
■
|
'Keep Incoming Via Headers': Via headers |
|
■
|
'Keep User-Agent Header': User-Agent headers |
|
■
|
'Keep Incoming Routing Headers': Record-Route headers |
|
■
|
'Remote Multiple Early Dialogs': To-header tags |
Thus, the Stateful Proxy mode provides full SIP transparency (no topology hiding) or asymmetric topology hiding. Below is an example of a SIP dialog-initiating request when operating in Stateful Proxy mode for full transparency, showing all the incoming SIP headers retained in the outgoing INVITE message.
Some of the reasons for implementing Stateful Proxy mode include:
|
■
|
B2BUA typically hides certain SIP headers for topology hiding. In specific setups, some SIP servers require the inclusion of these headers to know the history of the SIP request. In such setups, the requirement may be asymmetric topology hiding, whereby SIP traffic toward the SIP server must expose these headers whereas SIP traffic toward the users must not expose these headers. |
|
■
|
B2BUA changes the call identifiers between the inbound and outbound SBC legs and therefore, call parties may indicate call identifiers that are not relayed to the other leg. Some SIP functionalities are achieved by conveying the SIP call identifiers either in SIP specific headers (e.g., Replaces) or in the message bodies (e.g. Dialog Info in an XML body). |
|
■
|
In some setups, the SIP client authenticates using a hash that is performed on one or more of the headers that B2BUA changes (removes). Therefore, implementing B2BUA would cause authentication to fail. |
|
■
|
For facilitating debugging procedures, some administrators require that the value in the Call-ID header remains unchanged between the inbound and outbound SBC legs. As B2BUA changes the Call-ID header, such debugging requirements would fail. |
The operating mode can be configured per the following configuration entities:
If the operation mode is configured in both tables, the operation mode of the IP Group is applied. Once configured, the device uses default settings in the IP Profiles table for handling the SIP headers, as mentioned previously. However, you can change the default settings to enable partial transparency.
|
●
|
The To-header tag remains the same for inbound and outbound legs of the dialog, regardless of operation mode. |
|
●
|
If the Operation Mode of the SRD\IP Group of one leg of the dialog is set to 'Call Stateful Proxy', the device also operates in this mode on the other leg with regards to the dialog identifiers (Call-ID header, tags, CSeq header). |
|
●
|
It is recommended to implement the B2BUA mode, unless one of the reasons mentioned previously is required. B2BUA supports all the device's feature-rich offerings, while Stateful Proxy may offer only limited support. The following features are not supported when in Stateful Proxy mode: |
|
●
|
If Stateful Proxy mode is enabled and any one of the unsupported features is enabled, the device disables the Stateful Proxy mode and operates in B2BUA mode. |
|
●
|
You can configure the device to operate in both B2BUA and Stateful Proxy modes for the same users. This is typically implemented when users need to communicate with different SIP entities (IP Groups). For example, B2BUA mode for calls destined to a SIP Trunk and Stateful Proxy mode for calls destined to an IP PBX. The configuration is done using IP Groups and SRDs. |
|
●
|
If Stateful Proxy mode is used only due to the debugging benefits, it is recommended to configure the device to only forward the Call-ID header unchanged |